This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal


~Richard Nimfoogengon
Mar 26, 2015, 4:03 PM
26 Posts

Domino Server does not offer TLS when acting as SMTP client

  • Category: Administration
  • Platform: Windows
  • Release: 9.0.1
  • Role: Administrator
  • Tags: SSL,TLS
  • Replies: 8

Hello,

I have a Domino Cluster Release 9.0.1FP3 HF75 on Win32.

We use them for outgoing and incoming SMTP.

The SSL Handshake starts with a client hello where the client offers the highest SSL/TLS Version available. In our case it's our Domino Server who wants to send an Email and acts as a SMTP-Client.

Normally it looks like this:

[0E30:000E-0C1C] 26.03.2015 10:12:42,98 SSLEncodeClientHello> We offered SSL/TLS version TLS1.0 (0x0301)

And the Server answers:

[0E30:000E-0C1C] 26.03.2015 10:12:43,00 SSLProcessServerHello> Server chose SSL/TLS version TLS1.0 (0x0301)

But From Time to Time our Domino Server only offers SSLV3:

[0E30:001A-1374] 26.03.2015 14:01:54,39 SSLEncodeClientHello> We offered SSL/TLS version SSLV3.0 (0x0300)

Some Servers accept this but some others close the connection immediately.

 

Does anyone know a reason for the behaviour? I can't find any pattern in the occurences.

Is it possible to keep Domino from offering SSLV3 when acting as client?

 

Many thanks in advance

Ronald

~Richard Nimfoogengon
Mar 26, 2015, 5:13 PM
26 Posts
No, and I won't

Thanks for the answer, but this solution is not applicable for me.

I need SSLV3 when acting as Server, but I need to disallow it when acting as a  Client.

That's because I still have internal relays that don't support TLS.

The Mailn question to me is: why does it only offer SSLV3 although it is supporting TLS1.0?

And why does this happen only sometimes? 

In 99% of all cases it offers TLS 1.0.

~Dexter Deswechekynds
Mar 26, 2015, 9:05 PM
191 Posts
Look for anything with SSL in notes.ini
Take a look at notes.ini and see if you have anything set that contains the string "SSL". If you do, please post them here. Also set DEBUG_SSL_HANDSHAKE=2 and let's have a look at the debug when this occurs (please keep the other debug in place).
~Richard Nimfoogengon
Mar 27, 2015, 9:36 AM
26 Posts
This is debug output

Hello Chad,

please look at my initial Posting. This already is debug output from debug_ssl_handshake=2

I give you an Example for a "good" handshake:

[0150:000F-15E4] 26.03.2015 11:07:30,45 int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]     This is the Start of the negotiation
[0150:000F-15E4] 26.03.2015 11:07:30,45 SSL_Handshake> Enter
[0150:000F-15E4] 26.03.2015 11:07:30,45 SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
[0150:000F-15E4] 26.03.2015 11:07:30,45 SSLEncodeClientHello> We offered SSL/TLS version TLS1.0 (0x0301)       The Client (our Server) offers his highest available Version
[0150:000F-15E4] 26.03.2015 11:07:30,61 SSLProcessServerHello> Server chose SSL/TLS version TLS1.0 (0x0301)  The Server chooses 
[0150:000F-15E4] 26.03.2015 11:07:30,61 SSL_Handshake> After handshake state= 8 Status= -5000

After that, they negotiate the Cipher, exchange Certs and so on.

But from Time Time, without any visible reason, our Server starts different:

[0150:000F-15E4] 26.03.2015 11:53:48,44 int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]
[0150:000F-15E4] 26.03.2015 11:53:48,44 SSL_Handshake> Enter
[0150:000F-15E4] 26.03.2015 11:53:48,46 SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
[0150:000F-15E4] 26.03.2015 11:53:48,46 SSLEncodeClientHello> We offered SSL/TLS version SSLV3.0 (0x0300)  Here our Server offers SSLV3 instead of TLS1.0 as highest available Version,  why?
[0150:000F-15E4] 26.03.2015 11:53:48,46 SSLProcessServerHello> Server chose SSL/TLS version SSLV3.0 (0x0300) In this case the receiving server says "ok, let's do SSL"
[0150:000F-15E4] 26.03.2015 11:53:48,46 SSL_Handshake> After handshake state= 8 Status= -5000
[0150:000F-15E4] 26.03.2015 11:53:48,47 SSL_Handshake> Exit Status = -5000
[0150:000F-15E4] 26.03.2015 11:53:48,47 int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]
[0150:000F-15E4] 26.03.2015 11:53:48,47 SSL_Handshake> Enter

Or another one:

[0150:000F-15E4] 26.03.2015 11:56:27,03 int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]
[0150:000F-15E4] 26.03.2015 11:56:27,03 SSL_Handshake> Enter
[0150:000F-15E4] 26.03.2015 11:56:27,03 SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
[0150:000F-15E4] 26.03.2015 11:56:27,03 SSLEncodeClientHello> We offered SSL/TLS version SSLV3.0 (0x0300)    Again our Server offers SSLV3 instead of TLS1.0 as highest available Version
[0150:000F-15E4] 26.03.2015 11:56:27,06 SSLProcessAlert> Got an alert of 0x28 (handshake_failure) level 0x2 (fatal)  Receiving Server rejects Connection because SSL is disabled on his side
[0150:000F-15E4] 26.03.2015 11:56:27,06 SSL_Handshake> After handshake state= 5 Status= -6991
[0150:000F-15E4] 26.03.2015 11:56:27,06 SSL_Handshake> Exit Status = -6991
[0150:000F-15E4] 26.03.2015 11:56:27,06 int_MapSSLError> Mapping SSL error -6991 to 4161 [SSLSessionNotFoundErr]
[0150:000F-15E4] 26.03.2015 11:56:27   [0150:000F-15E4] SMTPClient: SSL handshake error: 1C7Bh

 

The Questions are: Why does the Domino Server sometimes offer SSLV3 as highest available Version? Is this a known bug? Has someone heard about this behaviour before?

Are there undocumented notes.ini parameter to deactivate SSLV3 only for outgoing Connections? Similar to 

O ServerSSLOptions=+SSL_OP_NO_SSLv3

O ClientSSLOptions=+SSL_OP_NO_SSLv3

In Sendmail Configuration.

 

Best Regards 

Ron

~Tanita Desweverobu
Mar 27, 2015, 1:17 PM
94 Posts
This sounds like SSL/TLS session resumption
When an SSL/TLS client successfully connects to an SSL/TLS server, it generally saves some context about that session that allows it to more quickly re-establish a ... similar ... session in the future. This process is called session resumption, and it remembers a great deal of cryptographic information about the initial session, including the negotiated protocol version.

If your SMTP server is connecting outbound to a destination server via a sprayer-type device, you could be hitting a server that only supports SSLv3, remembering that session, then trying to resume that session against a different server behind the sprayer that doesn't support SSLv3.
~Richard Nimfoogengon
Mar 27, 2015, 5:34 PM
26 Posts
Very interesting Point

This sounds really interesting. Something like a cache for the last successfull connection with a certain server.

We have that very special problem in 99% of all cases with the central Mail-Gateway of our holding company.

It is a McAfee Email Gateway (MEG) with which we randomly have problems of all kind. We are addressing a Loadbalancer with six appliances behind. We never know whitch of these we hit.

If your theory is right, There must be a successfull connection with SSLV3 to the receiving system in the logs.

I have collected tons of logs with debug_ssl_handshake=2 and I will check them next week.

It's Friday half past six in Germany and I'm going home now. Nice Weekend for all!

~Richard Nimfoogengon
Mar 31, 2015, 4:29 PM
26 Posts
Found nothing

Hello,

I was searching the Logs for something to prove the theory of Dave, and found nothing.

There was no successfull Connection with SSL V3 to the MEG-Box.

I watched the last events before our server offered SSL V3 

1. there was a successfull TLS connection with that MEG-Box

2. an incoming connection (TLS)

3. an outgoing connection to another server (TLS)

4. Our server offered SSL V3 to the MEG-Box

Not the smallest Hint of a reason why our server is doing that. I'm stuck.

~Richard Nimfoogengon
Apr 1, 2015, 1:22 PM
26 Posts
Additional Information

Today I have installed the interim Fix to support TLS 1.2 and the behaviour has changed!

Now it normally offers TLS 1.2 but from time to time it only offers TLS 1.0.

It seems to be a systematic misfunction that only the second best is presented as the best available.

And it looks like the Domino Server first offers a Cipher-List (containing ciphers that are only supported by TLS 1.2) and then offers TLS 1.0 as the highest available.

If the connected Server chooses a cipher that is not supported by TLS 1.0, the connection crashes.

Example:

[1DD0:0018-0E4C] 01.04.2015 11:47:49,99 SSLInitContext> 0 Available cipherspec: 0x009D
[1DD0:0018-0E4C] 01.04.2015 11:47:49,99 SSLInitContext> 1 Available cipherspec: 0x009C
[1DD0:0018-0E4C] 01.04.2015 11:47:49,99 SSLInitContext> 2 Available cipherspec: 0x003D
[1DD0:0018-0E4C] 01.04.2015 11:47:49,99 SSLInitContext> 3 Available cipherspec: 0x0035
[1DD0:0018-0E4C] 01.04.2015 11:47:49,99 SSLInitContext> 4 Available cipherspec: 0x003C
[1DD0:0018-0E4C] 01.04.2015 11:47:49,99 SSLInitContext> 5 Available cipherspec: 0x002F
[1DD0:0018-0E4C] 01.04.2015 11:47:49,99 SSLInitContext> 6 Available cipherspec: 0x000A
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 SSL_TRUSTPOLICY>  bits for signature hashes: 0004
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 int_MapSSLError> Mapping SSL error 0 to 0 [SSLNoErr]
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 SSL_Handshake> Enter
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 SSL_Handshake> Current Cipher 0x0000 (Unknown Cipher)
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 SSL_Handshake> outgoing ->protocolVersion: 0303
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 SSLEncodeClientHello> We offered SSL/TLS version TLS1.0 (0x0301)
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 SSLProcessServerHello> Server chose SSL/TLS version TLS1.0 (0x0301)
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 SSLProcessServerHello> Server chose cipher spec RSA_WITH_AES_256_CBC_SHA256 (0x003D)
[1DD0:0018-0E4C] 01.04.2015 11:47:50,01 FindCipherSpec> Cipher spec RSA_WITH_AES_256_CBC_SHA256 is not supported with TLS1.0
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 SSLSendAlert> Sending an alert of 0x2F (illegal_parameter) level 0x2 (fatal)
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 SSL_Handshake> After handshake state= 2 Status= -5000
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 SSL_Handshake> Exit Status = -5000
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 int_MapSSLError> Mapping SSL error -5000 to 4176 [SSLHandshakeNoDone]
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 SSL_Handshake> Enter
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 SSL_Handshake> Current Cipher 0x003D (RSA_WITH_AES_256_CBC_SHA256)
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 SSL_Handshake> After handshake2 state 2
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 SSL_Handshake> SSL Error: -6996
[1DD0:0018-0E4C] 01.04.2015 11:47:50,02 int_MapSSLError> Mapping SSL error -6996 to 4166 [SSLProtocolErr]


This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal